External tools such as Jujutsu may add many references that are of no
interest to the user. This preference allows hiding them.

Signed-off-by: Ori Avtalion <ori@avtalion.name>

gitk's color selection dialog uses a number of "label" widgets to show
the current value of each selectable color. This uses the -background
color property of label widgets, and this property is overwritten when
the full ui color set is refreshed. The swatch colors are set
individually using code passed into the chooser dialog, so there is no
common routine to set all after updating the global ui colors.

Let's replace this with a single routine that does set all swatches,
removing a key impediment to restoring the ui colors if the dialog is
cancelled.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

gitk provides a dialog to configure many ui colors. Any color element
changed in the dialog takes immediate effect before closing the dialog.
While cancelling the dialog after changing one or more colors avoids
saving the modified colors, the user must restart gitk to restore the
prior color set. This unfortunate behavior results because gitk does not
have a single routine to update all of the ui colors. The prior commit
eliminated the key impediment to having such a routine. So, let's create
a routine to update all configured colors at once, use this when
modifying colors, and also invoke this after restoring the prior set if
the dialog is cancelled.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

TclTk 8.7 (still in alpha), and 9.0 (released), implement TIP 474 that
delivers uniform handling of mouse and touchpad scrolling events on all
platforms, and by default bound to most widgets. TIP 474 also implements
use of the Option- modifier key (Alt- key on PC, Option- key on Macs) to
indicate desire for more motion per scroll wheel event, the
amplification is not defined but seems to be 5x to 10x.

So, for TclTk >= 8.7 we can use identical MouseWheel bindings on all
platforms, and should enable use of the Option- modifier to enable
larger motion. Let's do all of this, and use a 5x multiplier for the
Option- modifier.

This largely follows the prior win32 model, except that Tk 8.6 does not
reliably use the Option- modifier because the Alt- key conflicts with
builtin behavior to activate the main menubar. Presumably this conflict
is addressed in the win32 Tcl9.x package.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

gitk uses '-encoding binary' in several places to handle non-text data.
Per TIP 699, this is not recommended as there has been too much
confusion and misconfiguration of binary channels, and this option is
removed in Tcl 9.

Tcl defines a binary channel as one that reproduces the input data
exactly. As Tcl stores all data internally in unicode format, a binary
channel requires 3 things:
-  -encoding iso8859-1 : this causes each byte of input to be translated
   to its unicode equivalent (may be multi-byte).
-  -translation lf : this avoids any translation of line endings, which
   by default are translated to \n on input.
-  -eofchar {} : this avoids any use of an end of file character, which
   is ctrl-z by default on Windows.

The recommended '-translation binary' makes all three settings, but this
is not done in gitk now. Rather, gitk uses '-encoding binary', which is
an alias to '-encoding iso8859-1' removed by TIP 699, in multiple places,
and -eofchar {} in one place but not all. All other files, configured in
non-binary fashion, have -eofchar {}.

Unix and Windows differ on line ending conventions, Tcl by default
converts line endings to \n on input, and to those common on the
platform on output. git emits only \n on Unix or Windows. Also, Tcl's
proc gets recognizes and removes \n, \r, or \r\n as line endings, and
this is used by gitk except in procs selectline and parsecommit. But,
those two procs recognize any combination of \n and \r as terminating a
line. So, there is no need to translate line endings on input, and using
-translation binary avoids any such translation.

Tcl sets eofchar to ctrl-z (ascii \0x1a) only on Windows, otherwise
eofchar is {}. This provides compatibility to old DOS based codes and
files originating when file systems recorded only sectors allocated, and
not bytes used. git does not use ctrl-z to terminate data anywhere. Only
two channels in gitk leave eofchar at the default value, both use
-encoding binary now. A third one was converted in commit 681c329
("gitk: Handle blobs containing a DOS end-of-file marker", 2009-03-16),
fixing such a problem of early data termination. Using eofchar {} is
correct, even if not always necessary.

Tcl 9 forces change, using -translation binary per TIP 699 does what
gitk needs and is backwards compatible to Tcl 8.x. Do it.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

gitk looks for configuration files under $(HOME)/.., and uses the
typical shortcut formats to find this, e.g., ~/.config/. This relies
upon Tcl expanding such constructs to replace ~ with $(HOME). But, Tcl 9
has stopped doing that for various reasons, and now supplies [file
tildeexpand ...] to perform this expansion.

There are a very few places that need this expansion, and all must be
modified regardless of approach taken.

POSIX specifies that $HOME be defined at the time of login, and both
Cygwin and MSYS (underlying git for windows) set this variable. Tcl8
uses the POSIX defined pwnam to look up the underlying database record
on Unix, but will get the same result as using $HOME on any POSIX
compliant system. On Windows, Tcl just accesses $HOME, falling back to
other environment variables if $HOME is not set.  Git for Windows has
$HOME defined by MSYS, so this works just as on the others.

As $env(HOME) works in Tcl 8 and 9, while anything using [file
tildeexpand ... ] will not, let's use the simpler approach as doing so
adds no lines of code.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

gitk invokes many git commands expecting output in utf-8 encoding, but
git accepts extended ascii (code page unknown) as utf-8 without
validating, so cannot guarantee valid utf-8 on output.  In particular,
using any extended ascii code page, of which there are many, has long
been acceptable given that everyone on a project is aware of and uses
that same code page to view all data. utf-8 accepts only 7-bit ascii
characters in single bytes, and any characters outside of that base set
require at least two bytes.

Tcl is a string based language, and transcodes all input data to an
internal unicode format, and to whatever format is requested on output:
"pure" binary is recoded using iso8859-1.  Tcl8.x silently recodes
invalid utf-8 as binary data, so extended ascii characters maintain
their binary value on output but may not display correctly.

Tcl 8.7 added three profiles to control this behaviour: strict (raises
exceptions), replace (replaces each invalid byte with ?), and the
default tcl8 maintaining the old behavior.  Tcl 9 changes the default
profile to strict, meaning any invalid utf-8 raises an exception that
gitk does not handle.

An example of this in the git repository is commit 7eb93c8 ("[PATCH]
Simplify git script", 2005-09-07). This includes extended ascii
characters in the author name and commit message. As a result, gitk +
Tcl 9 cannot view the git repository at any point beyond that commit.
Note: Tcl 9.0 has a bug, to be fixed in 9.1, where this particular
condition results in a memory error causing Tcl to crash [1].

The tcl8 profile used so far has acceptable behavior given gitk's
acceptance: this allows gitk to accept extended ascii though it may
display incorrectly.  Let's continue that behavior by overriding open to
use the tcl8 profile on Tcl9 and later: Tcl 8.6 does not understand
fconfigure -profile, and Tcl 8.7 maintains the tcl8 profile.

[1] Per https://core.tcl-lang.org/tcl/tktview/73bb42fb3f35cd613af6fcea465e35bbfd352216

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

gitk in the prior commit learned to apply -profile tcl8 to all input
data streams, avoiding errors on non-binary data streams whose encoding
is not utf-8. But, gitk also consumes binary data streams (generally blobs
from commits), and internally decodes this to support various displays.

With Tcl9, errors occur in this decoding for the same reasons described
in the previous commit: basically, the underlying data was not validated
to conform to the given encoding, and this source encoding may not be
utf-8. gitk performs this decoding using Tcl's '[encoding convert from'
operator.

For example, the 7th commit in gitk's history has the extended ascii
value 0xA9, so

	gitk 9a40c50

in gitk's repository raises an exception. The error log has:

unexpected byte sequence starting at index 11: '\xA9'
    while executing
"encoding convertfrom $diffencoding $line"
    (procedure "parseblobdiffline" line 135)
    invoked from within
"parseblobdiffline $ids $line"
    (procedure "getblobdiffline" line 16)
    invoked from within
"getblobdiffline file6 9a40c50"
    ("eval" body line 1)
    invoked from within
"eval $script"
    (procedure "dorunq" line 11)
    invoked from within
"dorunq"
    ("after" script)

This problem has a similar fix to the prior issue: we must use the tlc8
profile when converting this data. Do so, again only on Tcl9 as Tcl8.6
does not recognize -profile, and only Tcl 9.0 makes strict the default.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

Tcl/Tk 9.0 has been released, and has shipped in Fedora 42. Prior
patches in this sequence have addressed known incompatibilities, so gitk
is now operating with Tcl9. So, let's allow Tcl9.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

git-gui on Windows prepends three directories to PATH so does not honor
PATH as configured. This can have undesirable consequences, for instance
by preventing use of a different git for testing.  This also provides at
best a subset of the configuration included with Git for Windows (g4w),
so is neither necessary nor sufficient there.

Since commit be700fe, git-gui.sh adds its directory to the front of
PATH: this is essentially adding $(git --execdir) to the path, this is
long deprecated as git moved to using "dashless" subcommands.

The windows/git-gui.sh wrapper file, since commit 99fe594, adds two
directories relative to its installed location to PATH, and does so
without checking that either exists or is needed.

The above modifications were made before the Git For Windows project
took responsibility for distributing a working solution on Windows. g4w
assures a correct configuration on Windows without these, and doing so
requires more than the above modifications.  See [1] for a more thorough
treatment.

git-gui does not modify PATH on any platform except on Windows, and
doing so is not needed by g4w.  Let's stop modifying PATH on Windows as
well.

[1] https://gitforwindows.org/git-wrapper.html

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

git-gui runs blame and diff commands with nice by default. On Unix, nice
is accepted if found and it will run git. Commit ff9db6c ("On
Windows, avoid git-gui to call Cygwin's nice utility", 2010-10-05)
rejects nice if not collocated with git. In Git for Windows' (g4w) POSIX
path name space, nice and git are found in different directories:

	$ which git
	/mingw64/bin/git
	$ which nice
	/usr/bin/nice

Thus, git-gui will not use nice in the supported Windows configuration.
Commit ff9db6c justifies the collocation requirement as avoiding
problems in a mixed MSYS and Cygwin configuration: such configurations
are not supported by either project as they are known to cause many
problems.

So, let's revert ff9db6c and let git-gui work correctly in the
supported configuration.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

git-gui invokes the tk_getSaveFile dialog to determine the full
path-name of the shortcut file to create. But, on Windows, this dialog
always dereferences a shortcut (.lnk) file, as this is essentially a
soft-link to its target. If the shortcut file already exists, the dialog
returns the path-name of the target (i.e., GIT/cmd/git-gui.exe), and not
the desired shortcut file selected by the user.

There is no Windows file chooser available in Tcl/Tk that does not
dereference .lnk files, so this patch avoids using a dialog: the
shortcut to be created is on the desktop and named as "Git + Repository
Name". If this .lnk file already exists, the user must give permission
to overwrite it or the process terminates.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

git-gui on Windows creates a shortcut that presumes the git-gui script
will run on the basic Windows environment as configured. But, Git for
Windows uses wrapper scripts to launch executables, assuring the
environment is correct (see [1] for details). The launcher for git-gui
is /cmd/git-gui.exe, is not on PATH, and is not detected or used by the
current shortcut code. Let's look for this before trying the existing
approaches.

[1] https://gitforwindows.org/git-wrapper.html

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

Per 6eb420e ("git-gui: Always disable the Tcl EOF character when
reading", 2007-07-17), git-gui should disable Tcl's EOF character
detection on all files when on Windows: the default is disabled on all
other platforms (and with Tcl 9.0, is disabled on Windows too).  This
EOF character is for compatibility with files / applications written for
file systems that know only the disc sectors allocated, and not the
number of bytes used.  This has nothing to do with git.

But, git-gui does not set -eofchar {} on all channels.  To avoid any
further leakage, let's just add this to the Windows specific override of
open.  This override is needed only as long as Tcl 8.x is in use (Tcl
9.0 makes -eofchar {} default on all platforms).

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

git-gui has many cases where -translation binary and -encoding binary
are configured on the same channel. But, -translation binary defines a
binary channel, which sets up -encoding iso8859-1 as part of its work.
Tcl 8.x defines -encoding binary as an alias of -encoding iso8859-1, and
this alias is deleted in Tcl 9.0.  Let's delete the redundant encoding
definition now.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

git-gui currently configures some channels as '-encoding binary' when
the channel is not really binary (e.g, the channel is consumed as lines
of text).  In 8.6, '-encoding binary' is an alias for '-encoding
iso8859), but TIP 699 removes this alias for Tcl 9.0. Let's switch to
'-encoding iso8859-1' to be compatible across Tcl versions.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

git-gui has many instances of '-translation binary' and '-encoding
$SOMETHING' on the same channel.  As eofchar is always null given a
prior commit, the net effect of having '-translation binary' in such
configuration is only to change how text line endings are handled.

For cases where the channel is opened to be consumed via gets, the eol
translation is irrelevant because Tcl's gets is documented to recognize
any of \n, \r, and \r\n as a line ending.  So, keep only the '-encoding
$SOMETHING' configuration in these cases, making the configuration more
clear.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

Signed-off-by: Alexander Shopov <ash@kambanaria.org>

This makes sending diffs via mail list easier and
brings the po-file in line with git po-file.

Signed-off-by: Alexander Shopov <ash@kambanaria.org>

Signed-off-by: Alexander Shopov <ash@kambanaria.org>

This makes sending diffs via mail list easier and
brings the po-file in line with git po-file.

Signed-off-by: Alexander Shopov <ash@kambanaria.org>

It is possible that multiple local branches track the same upstream.
In this case, the refs dialog lists the tracked upstream branch
multiple times. This is undesirable. Make them unique.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

In refill_reflist, upstream refs are now only included if their
commits are visible in the current view. This prevents display
issues like multiple highlighted branches when clicking entries.

Signed-off-by: Michael Rappazzo <michael.rappazzo@infor.com>

Last used in ae49066 (git gui Makefile - remove Cygwin modifications,
2023-06-26), and unused since.

Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>

Since 854e883 (git-gui: extract script to generate "git-gui",
2025-03-11), the logic to generate the main script was pulled
out of the Makefile, but adding the resulting generator as a
dependency was missed.

If the logic changes, the main script should be regenerated, so
add it as a dependency.

Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>

In a recent commit, the minimum version of Tcl/Tk was raised to
8.6, but the "app" relies on the system provided Framework that
is based on 8.5.

Remove it, and let git-gui use a third party version of Wish if
available.

Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>

Since its introduction in 8c76212 (git-gui: Add a simple implementation
of SSH_ASKPASS., 2008-10-15), git-gui--askpass has been calling whatever
wish interpreter is in the path, unlike git-gui.

Correct that by turning it into a script that would be processed at build
time.

Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>

* ml/windows-tie-loose-ends:
  git-gui: use /cmd/git-gui.exe for shortcut
  git-gui: Windows tk_getSaveFile is not useful for shortcuts
  git-gui: let nice work on Windows
  git-gui: do not add directories to PATH on Windows

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

git-gui configures '-translation lf' on a number of channels. The
default configuration is 'auto', which on input changes any occurrence
of \n, \r, or \r\n to \n, and on output changes any such EOL sequence to
a platform dependent value (\n on Unix, \r\n on Windows). Such
translation can be necessary, but much of what is configured now is
redundant.

In particular, many of the channels configured this way are then
consumed by gets, which already recognizes any of \n, \r, or \r\n as
terminators.  Configuring a channel to first change these line endings,
then give the result to gets, is redundant.

The valid uses of -translation lf are for output where we do not want
\r\n on Windows, and for consuming entire files without going through
gets, assuring that \n will be used internally. Let's remove all the
others that only serve to confuse.

lib/diff.tcl must have -translation lf because \r\n might be stored in
the repository (e.g., on Windows, with no crlf translation enabled), and
git will treat \n as the line ending, while the preceding \r is just
whitespace, and these may be split by ANSI color coding. git-gui's
read_diff handles this correctly as-is.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

git-gui invokes many git commands expecting output in utf-8 encoding,
but git accepts extended ascii (code page unknown) as utf-8 without
validating, so cannot guarantee valid utf-8 on output.  In particular,
using any extended ascii code page has long been acceptable on git given
that everyone on a project is aware of and uses that same code page to
view all data. utf-8 accepts only 7-bit ascii characters in single
bytes, and any characters outside of that base set require at least two
bytes for representation in unicode.

Tcl is a string based language, and transcodes all input data to an
internal unicode format, and to whatever format is requested on output:
"pure" binary is recoded byte by byte using iso8859-1.  Tcl8.x silently
recodes invalid utf-8 as binary data, so extended ascii characters
maintain their binary value on output but may not display correctly.

Tcl 8.7 added three profiles to control this behaviour: strict (raises
exceptions), replace (replaces each invalid byte with ?), and the
default tcl8 maintaining the old behavior.  Tcl 9 changes the default
profile to strict, meaning any invalid utf-8 raises an exception that
git-gui does not handle.

An example of this in the git repository is commit 7eb93c8 ("[PATCH]
Simplify git script", 2005-09-07). This includes extended ascii
characters in the author name and commit message.

The tcl8 profile used so far has acceptable behavior given git-gui's
acceptance: this allows git-gui to accept extended ascii though it may
display incorrectly.  Let's continue that behavior by overriding open to
use the tcl8 profile on Tcl9 and later: Tcl 8.6 does not understand
fconfigure -profile, and Tcl 8.7 maintains the tcl8 profile.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

git-gui in the prior commit learned to apply -profile tcl8 when reading
files, avoiding errors on non-binary data streams whose encoding is not
utf-8. But, git-gui also consumes binary data streams (generally blobs
from commits) as the output of commands, and internally decodes this to
support various displays.

With Tcl9, errors occur in this decoding for the same reasons described
in the previous commit: basically, the underlying data may contain
extended ascii characters violating the assumption of utf-8 encoding.

This problem has a similar fix to the prior issue: we must use the tlc8
profile when converting this data to the internal unicode format. Do so,
again only on Tcl9 as Tcl8.6 does not recognize -profile, and only Tcl
9.0 makes strict the default.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

TclTk 9.0 is now shipping, and git-gui is now patched to support use of
this newer version. Adjust required versions to allow Tcl/Tk >= 8.6,
including 9.x.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>

* mr/sort-refs-by-type:
  gitk: filter invisible upstream refs from reference list
  gitk: avoid duplicated upstream refs

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

* 'master' of github.com:alshopov/gitk:
  gitk i18n: Remove the locations within the Bulgarian translation
  gitk i18n: Update Bulgarian translation (322t)

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

* ml/abandon-old-version:
  gitk: restore ui colors after cancelling config dialog
  gitk: set config dialog color swatches in one place

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

* oa/hide-more-refs:
  gitk: Add user preference to hide specific references

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

* ml/tcltk-9:
  gitk: allow Tcl/Tk 9.0+
  gitk: use -profile tcl8 on encoding conversions
  gitk: use -profile tcl8 for file input with Tcl 9
  gitk: Tcl9 doesn't expand ~, use $env(HOME)
  gitk: switch to -translation binary
  gitk: update scrolling for TclTk 8.7+ / TIP 474

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

* 'master' of https://github.com/alshopov/git-gui:
  git-gui i18n: Remove the locations within the Bulgarian translation
  git-gui i18n: Update Bulgarian translation (557t)

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

* ml/tcl90:
  git-gui: Allow Tcl 9.0
  git-gui: use -profile tcl8 on encoding conversions
  git-gui: use -profile tcl8 for file input with Tcl 9
  git-gui: themed.tcl: use full namespace for color
  git-gui: remove EOL translation for gets
  git-gui: do not mix -translation binary and -encoding
  git-gui: replace encoding binary with iso8859-1
  git-gui: translation binary defines iso8859-1
  git-gui: assure -eofchar {} on all channels

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

* 'strip-post-hooks' of github.com:orgads/git-gui:
  git-gui: strip the commit message after running commit-msg hook

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

This clarifies that one has to enter e.g. `jj/keep/*` and not just
`jj/keep`.

Follows up on 2441e19.

Signed-off-by: Ilya Grigoriev <ilyagr@users.noreply.github.com>

* 'docglobs' of github.com:ilyagr/gitk:
  gitk: Mention globs in description of preference to hide custom refs

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

When finding a location for the askpass helper, git will be asked
for its exec path, but if that git is not the same that called
git-gui then we might mistakenly point to its helper instead.

Assume that git-gui and the helper are colocated to derive its
path instead.

This is specially useful in macOS where a broken version of that
helper is provided by the system git.

[j6t: move directory to variable to help in-flight topics]

Suggested-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>

* cb/no-tcl86-on-macos:
  git-gui: ensure own version of git-gui--askpass is used
  git-gui: honor TCLTK_PATH in git-gui--askpass
  git-gui: retire Git Gui.app
  git-gui: fix dependency of GITGUI_MAIN on generator
  git-gui: remove uname_O in Makefile

* 'master' of https://github.com/j6t/gitk:
  gitk: Mention globs in description of preference to hide custom refs
  gitk: filter invisible upstream refs from reference list
  gitk: avoid duplicated upstream refs
  gitk i18n: Remove the locations within the Bulgarian translation
  gitk i18n: Update Bulgarian translation (322t)
  gitk: allow Tcl/Tk 9.0+
  gitk: use -profile tcl8 on encoding conversions
  gitk: use -profile tcl8 for file input with Tcl 9
  gitk: Tcl9 doesn't expand ~, use $env(HOME)
  gitk: switch to -translation binary
  gitk: update scrolling for TclTk 8.7+ / TIP 474
  gitk: restore ui colors after cancelling config dialog
  gitk: set config dialog color swatches in one place
  gitk: Add user preference to hide specific references

* 'master' of https://github.com/j6t/git-gui: (21 commits)
  git-gui: ensure own version of git-gui--askpass is used
  git-gui: Allow Tcl 9.0
  git-gui: use -profile tcl8 on encoding conversions
  git-gui: use -profile tcl8 for file input with Tcl 9
  git-gui: themed.tcl: use full namespace for color
  git-gui: remove EOL translation for gets
  git-gui: honor TCLTK_PATH in git-gui--askpass
  git-gui: retire Git Gui.app
  git-gui: fix dependency of GITGUI_MAIN on generator
  git-gui: remove uname_O in Makefile
  git-gui i18n: Remove the locations within the Bulgarian translation
  git-gui i18n: Update Bulgarian translation (557t)
  git-gui: do not mix -translation binary and -encoding
  git-gui: replace encoding binary with iso8859-1
  git-gui: translation binary defines iso8859-1
  git-gui: assure -eofchar {} on all channels
  git-gui: use /cmd/git-gui.exe for shortcut
  git-gui: Windows tk_getSaveFile is not useful for shortcuts
  git-gui: let nice work on Windows
  git-gui: do not add directories to PATH on Windows
  ...